The present invention relates generally to a hardware control system and, more particularly, to a hardware control system for a medical imaging device to allow hardware control software and medical imaging applications to be independent.
When a substance such as human tissue is subjected to a uniform magnetic field (polarizing field B0), the individual magnetic moments of the spins in the tissue attempt to align with this polarizing field, but precess about it in random order at their characteristic Larmor frequency. If the substance, or tissue, is subjected to a magnetic field (excitation field B1) which is in the x-y plane and which is near the Larmor frequency, the net aligned moment, or “longitudinal magnetization”, MZ, may be rotated, or “tipped”, into the x-y plane to produce a net transverse magnetic moment Mt. A signal is emitted by the excited spins after the excitation signal B1 is terminated and this signal may be received and processed to form an image.
When utilizing these signals to produce images, magnetic field gradients (Gx Gy and Gz) are employed. Typically, the region to be imaged is scanned by a sequence of measurement cycles in which these gradients vary according to the particular localization method being used. The resulting set of received NMR signals are digitized and processed to reconstruct the image using one of many well known reconstruction techniques.
To implement these procedures a complex system of hardware and software is employed. Typically, the software applications used include batch applications and programs written to be processed individually and sequentially. In such a system, the software, both on the application level and the system level, is tailored specifically for a given hardware configuration. As such, a significant modification to the hardware of the system or to a desired application requires a revision of most, if not all, of the software. Furthermore, only the manufacturer is typically capable of this type of revision because only the manufacturer has a sufficient understanding of and access to the software to properly revise the software. This is particularly applicable to medical devices which must comply with federal regulations and standards.
For example, it is often desirable to update a medical imaging system by modifying the programmable pulse sequence. This is typically achieved by editing the source code of the software because the source code allows concise manipulation of variables and the greatest overall flexibility. However, as stated above, it is generally only the manufacturer that has access and is qualified to edit the source code. This can result in a costly and arduous updating process that may result in substantial downtime of the system.
It is generally known that the medical imaging field has been experiencing rapid growth, development and transition. This unprecedented growth adds to the difficulty of developing and improving medical imaging software and hardware to keep pace with the demands of physicians, technicians, and patients. Simply, the advances in technology have led consumers to demand the addition of new developments and improvements to existing medical imaging systems. In order to meet this demand, it is necessary to make such improvements more feasible by lowering the interdependence between medical imaging software and hardware.
The use of object-oriented programming is a step toward separating medical imaging software from hardware. Applications built with object-oriented programming are developed in a block-by-block or “object-by-object” fashion. An “object” is generally considered a programming component that can be used to build arrangements of variables and operations therein. These arrangements can be logically grouped onto “structures” or “classes.” Each “class” can be designed to perform a specific operation or operations on data passed to it by another class.
Also, the advent of hardware independent programming languages has enabled the separation of applications from specific operating systems or system software and the hardware controlled by the operating system. Accordingly, medical imaging systems have used the object oriented, hardware independent, programming language Java or similar hardware independent languages for application development. In a medical imaging system these applications reside on an operator console and are selected by a user. By using the Java programming language or a similar hardware independent language, applications may be developed without regard to the operator console hardware or operator console operating system. This division between the operator console and the application is possible using the Java programming language because the Java programming language is compiled into machine independent bytecode class files. Following compilation, the operator console is able to execute the compiled code written in the Java programming language by executing a virtual machine. The virtual machine provides the “bridge” between the machine independent byte code classes and the machine dependent instructions that must be given to cause the operator console to operate according to the application. This division between applications and the operator console operating system allows hardware changes to be made to the operator console with little or no modifications required in the application software. Thus, maximum portability is achieved with respect to application software since the application can operate regardless of the operating system or hardware.
While Java and similar programming languages have provided a means of developing portable applications, such languages cannot be used to develop software for system hardware control because it is necessary to use a programming language capable of direct communication with and control of system hardware. Other object oriented programming languages capable of facilitating real-time control of hardware, such as C++ and others, provide a structured syntax as well as linkers and compliers suitable to implement medical imaging system software for hardware control. However, while this tie between system hardware and system software provides real-time control of hardware, it lacks the ability to make changes to system hardware without requiring corresponding changes to system software.
Therefore, it would be desirable to have a system and method capable of allowing a wide variety of system hardware configurations and applications without requiring system wide or source code updates of the system hardware control software. The system should provide default measures for hardware interaction by an application, allow for new hardware to be added to the system without changing the application and allow a developer to access hardware information for improved maintenance.